… success

The install handler treated a partial or fully failed precache as non-fatal:
it called skipWaiting() unconditionally and activate then pruned every
prior cache generation regardless of whether the new one actually completed.
A transient network failure during precache could therefore replace a
working, complete cache with an incomplete one and destroy the fallback.

Install now stamps a synthetic admission marker into CACHE_STATIC only
after every precache URL succeeds, and only then calls skipWaiting() — a
failed precache leaves a currently-active prior generation fully in
control. Activate independently checks for that marker before pruning any
older generation; without it, every existing cache (including the last
known-good one) is left untouched, and a later successful install can
still admit and prune normally.

Catching a precache error without rethrowing let event.waitUntil() resolve
successfully, so a failed installation could still reach "installed" and
"waiting", later activate naturally, and call clients.claim() with an
incomplete cache. Once that worker controls pages, its own CACHE_STATIC/
CACHE_DYNAMIC constants point only at the new generation, so merely leaving
the previous generation's cache un-pruned in CacheStorage never meant it was
still being served.

The install handler now rethrows on precache/admission-marker failure so the
whole installation rejects. A worker whose install() rejects never reaches
"installed" or "waiting" (browser-native Service Worker lifecycle states),
so it can never activate, claim clients, or receive the app's SKIP_WAITING
update message (register-sw.ts only ever targets registration.waiting / a
worker whose state reached 'installed') — closing that path structurally,
with no additional gating needed in the message handler. The activate-side
admission-marker check is retained as defense in depth.

Regression tests now prove the lifecycle directly against the real install
and activate handlers: a failed precache rejects install and never calls
skipWaiting(); a successful install writes the marker and calls
skipWaiting(); a real second install attempt after a failed one still
succeeds normally. README's test-count metric is synced (7647 -> 7649)
for the resulting net test-count change.

…se in depth)

The markerless activate branch logged a warning and skipped pruning but
still fell through to clients.claim(), which is inconsistent with that
branch's defense-in-depth purpose: if admission can't be proven, that
generation should not take control of any page either. It now returns
immediately after the warning; only an admitted generation reaches
pruning and clients.claim(). The authoritative admission boundary remains
the rejected install() lifecycle from the prior commit — this only closes
the same gap for the (structurally unreachable) case where activate runs
anyway.

Strengthened the existing recovery test instead of adding a new one: it
now counts clients.claim() calls and asserts the count stays 0 through the
simulated markerless activate and becomes 1 only after the real second
successful install + activate.

… shell URLs

Two independent reviewers flagged that VitePWA's injectManifest globPatterns
(**/*.{js,css,html,svg,...}) sweep up index.html, offline.html and
favicon.svg into _WB_MANIFEST, which duplicates the same three URLs already
listed explicitly (with the deployment BASE prefix) in sw.js's own
PRECACHE_URLS. Verified empirically with a real production build: all three
appeared as bare manifest entries resolving to the same absolute URLs as the
explicit list, which cache.addAll() rejects with InvalidStateError on
duplicate requests. Combined with the prior commit's install-rejection fix,
this meant every production install would fail permanently, not just on a
genuine precache failure.

Excluded the three files from the injected manifest via globIgnores — they
are already correctly precached by the explicit list, and none of them are
content-hashed, so nothing is lost: cache invalidation for the whole static
generation already happens via the APP_VERSION-keyed cache name change, not
per-file manifest revisions. Re-built production output afterward and
confirmed all three no longer appear in the generated manifest (2502 -> 2499
entries, an exact -3).

Also fixed a real internal inconsistency a reviewer found in the test file:
ADMISSION_MARKER_URL hardcoded '/WorldScript-Studio/' while claiming to be
fully "extracted from source, not hardcoded" — only the suffix was. Factored
the hardcoded base into one shared TEST_BASE constant also used by
loadServiceWorker()'s selfMock.location.pathname, so the two can no longer
silently diverge.

…t revisions

The prior commit avoided cache.addAll()'s duplicate-request rejection by
excluding index.html, offline.html and favicon.svg from VitePWA's injected
manifest via vite.config.ts globIgnores. Review (chatgpt-codex-connector)
correctly identified that this throws away real signal: those entries carry
a content-hash revision that changes sw.js's own bytes whenever one of the
files is edited, which is what lets the browser detect and install an update
even when package.json's version isn't bumped. Removing them from the
manifest meant a content-only change to any of the three would silently ship
stale content to existing installs indefinitely.

Reverted the vite.config.ts exclusion — the manifest keeps full revision
tracking for these files again. Instead, sw.js's own PRECACHE_URLS
construction now resolves every manifest entry and every explicit shell URL
to an absolute URL and drops any manifest entry that collides with an
explicit one before the list ever reaches cache.addAll(). The revision data
stays embedded in sw.js's compiled source (still driving the update-detection
signal); only the redundant duplicate *request* is removed.

Strengthened the test harness to make this a real regression guard rather
than an assumption: the fake cache's addAll() now mirrors the real Cache API
by rejecting when two entries resolve to the identical absolute URL (it
previously silently deduped everything via a Set, which would have let this
exact bug pass unnoticed). Added a dedicated test with a synthetic manifest
containing entries that collide with the explicit shell list, confirming
install still succeeds. Mutation-tested by reverting the dedup logic and
confirming the new test fails with the expected simulated InvalidStateError,
then restored the fix.

Re-verified with a real production build: the manifest still carries
revision-tracked entries for all three files, and the final precache list
sent to addAll() contains no duplicates.

README test-count metric resynced via the authoritative `pnpm run
sync:readme` script rather than manual editing (7649 -> 7650 for the net new
test).

…plicit shell list

CodeRabbit correctly identified that the prior commit's dedup only compared
manifest URLs against EXPLICIT_SHELL_URLS, so two manifest entries that
resolved to the same URL as each other (without matching anything in the
explicit list) would still both reach cache.addAll() and trigger the same
InvalidStateError this whole fix exists to prevent. Now tracks every
resolved URL seen so far in one shared set, seeded with the explicit shell
URLs, so any manifest entry colliding with either the explicit list or an
earlier manifest entry is dropped.

Added a dedicated negative-path test with two manifest entries that collide
only with each other (not the explicit list), addressing a related finding
from cubic: the existing test only exercised the fake's duplicate-rejection
branch via entries that were already filtered by the explicit-list check,
so it didn't prove the rejection path was reachable through this second
class of collision. Mutation-tested by reverting the mutual-dedup logic and
confirming the new test fails with the expected simulated InvalidStateError,
then restored the fix. Re-built production output and confirmed the
manifest still carries revision-tracked entries for the three shell files.

README test-count metric auto-resynced by `pnpm run build`'s own prebuild
hook (7650 -> 7651 for the one net new test).